A graphical user interface (GUI) for a computer program is typically developed using a programming tool that provides the user with a development system having an editing mode that allows the user to layout various display elements that are used by the program in communicating with the user. Typically, the tool provides a “canvas” or form on which the program places and sizes various graphical elements that are used in communications between the end user and the program. A graphical element may be a box that is used to provide textual input to, or output from, the program, a button that is depressed by the user during the operation of the program, etc. The programmer writes code that processes the data input through the GUI and displays the results in corresponding graphical elements in the GUI. The code is then compiled to produce a runtime system, which the programmer uses to debug the program and generate the final application for use by the end user. The programming tool typically provides the compiler and software for debugging the application and providing the final runtime program for use by the end user.
The data displayed in the GUI may be generated solely within the program during the operation of the program, may be generated by a remote source, or be a combination of the two. Some of the locally generated data may be viewable during editing. For example, if a “text box” that receives textual information from the user has a default text message that is displayed, that text message can be shown in the text box graphical element even during the editing process.
In contrast, data that is being sent by a remote source that connects to the graphical element is not viewable in the graphical element until the program is actually compiled and running. As a result, the programmer cannot verify that the remote source/data are the correct source and data without compiling and running the program. To receive data or send data to a remote source, the program typically requires three sets of instructions. The first set establishes a connection between the program and remote source. The second set requests the data stream that is to be sent to the program, and the third set receives the data and displays it in the graphical element, with or without, further processing. The programmer needs to generate each of these sets correctly to just get the graphical element to display the data stream from the remote server. This process is tedious and error prone.
The connection sequence is particular to the server that is providing the data. The connection sequence typically requires user names and passwords encoded in a particular manner as well as an address that is used to access the server. The message in which the authorization information is provided is typically different for different servers. While the messages are often some form of text string, the format of the string will vary from source to source. If the string is incorrect, the programmer will typically just receive a message that the connection failed. The instructions in the second set of instructions also typically requires a text string that is different for different applications. If the programmer gets the string wrong, the programmer is again sent a message that the request failed with little or no information that allows the programmer to determine why the request failed. Finally, if the data stream is received but in a different format than the programmer anticipated, the programmer must determine if the stream has the desired data and figure out why the data is in the unanticipated format.
As a result of these complexities, the process of setting up a graphical element to display a remote data source often requires numerous passes in which the programmer modifies one of the instruction strings, recompiles the program and runs the program in a debug mode. Each time the stream fails, the user must adjust the strings and try again. The process is time consuming and frustrating. To reduce this complexity, various programming platforms provide tools for specific common server connections such as graphical elements that connect to a particular type of database and display data from a known table in that database. However, even with these tools, the user must compile and run the program to determine if the correct data stream is being received and displayed in the desired manner. Often, the program in question includes various other components that must be debugged before the portion that connects to the remote server and displays that data is written and debugged. This further complicates the problem of dealing with a remote data source, as errors in the other code can also interfere with the code dealing with the remote server.